Hardware communications infrastructure supporting location transparency and dynamic partial reconfiguration

ABSTRACT

A communication system according to one aspect of the present invention, comprises one or more integrated circuits. The one or more integrated circuits comprise at least one of a local integrated circuit and a remote integrated circuit. At least one sending application hardware module located on the local integrated circuit has a sending logic that controls the sending of messages from the sending application hardware module. At least one receiving application hardware module is located on at least one of the local integrated circuit or remote integrated circuit. A sending application hardware module sends messages to a receiving application hardware module without its sending logic having been constructed with a priori knowledge of the address of or the path to said receiving application hardware module. A dispatch logic located on the local integrated circuit that routes at least one or more.

FIELD OF INVENTION

The present invention relates generally to implementing a digitalintegrated circuit device within a communications network, and moreparticularly, to implementing an Object Request Broker (ORB) module on adigital integrated circuit device to enable communication with othercomputing devices within a distributed system.

BACKGROUND OF THE INVENTION

Distributed computing is a type of parallel processing in whichdifferent components of an application, i.e. software programs orhardware modules processing logic, run simultaneously on two or morecomputing device that communicate with each other over a network. Anapplication component may make an invocation, communication, or call toanother component running on a different computing device, requesting acertain function to be performed or certain data to be returned. Theseapplication components may operate in different computing environments,e.g. different hardware platforms, operating systems, and programminglanguages. For example, two software programs within a distributedapplication may be written in different programming language andexecuted on different operating systems running on different processors.It is often difficult for a developer to implement a call directly fromone such application component to another if the two components aredesigned and operated within different and incompatible computingenvironments. Therefore, there must be a common communication medium toallow these application components to interoperate and interact with oneanother.

In a conventional distributed system processing a distributedapplication software, a middleware component referred to as an ObjectRequest Broker (ORB) is used to enable software programs operatingwithin different computing environments to communicate with one anotherover a network. An ORB transforms data structures from one computingplatform to a sequence of bytes which can be transmitted over thenetwork and received by another computing platform. At the receivingcomputing platform, the ORB transforms the sequence of bytes todata-structures understood by the receiving computing platform. The ORBalso provides transparency to the programs running within thedistributed system, so that a program resident on a computing platformwithin the ORB can communicate with another program resident on a remotecomputing platform, without needing to know the location of the program,the type of platform where the program is executed, or operating systemthat executes the program.

ORBs communicate with each other via an abstract protocol referred tothe General Inter-ORB Protocol (GIOP). The GIOP defines the format ofdata and syntax of messages transported through the network. Thestandards associated with the GIOP are maintained by the ObjectManagement Group (OMG). The OMG also defines an architectural model of adistributed system referred to as the Common Object Request BrokerArchitecture (CORBA). For every application component within thedistributed system, CORBA creates a bundle containing information aboutthe capabilities of the logic inside and how to invoke it. CORBA uses anInterface Definition Language (IDL) to describe the interfaces thatobjects present to the world. The IDL describe an interface in alanguage-neutral way, so that software components that do not share acommon programming language or compilation platform can communicate withone another. CORBA also defines a mapping for different programminglanguages such as Ada, C, C++, or Java, to communicate with the IDL.

A simplified model of a CORBA system is discussed with reference toFIG. 1. In this figure, the network 110 delivers a request from a clientcomputer 120 to a server computer 130. An ORB Repository (not shown)stores a list of all objects, such as object X, available for executionon all computers on the network 110. The Client ORB 110 may access theORB Repository and provides the client computer 120 with informationabout all objects, such as object X, executable through the ORB. In thisexample, the object X includes a method “fire”. Although the object X isstored in and is executed by the server computer 130, that code iscompletely transparent to program 122 on the client computer 120. Theprogram 122 need not know the programming language used by the program132 or the operating system running on the server computer 130. Thus,from the perspective of the program 122, it makes a call to object X thesame way as it would call any local object.

The program 122 may invoke the object X to perform the method “fire” bysending this request to client ORB 124, which provides an interface forobject X to the computer 120. The client ORB 124 uses the IDL stubs 126,which are pre-compiled from IDL and define how the client computer 120can invoke the object X on server computer 130. There is an IDL stub foreach interface that the client computer 120 uses on another computer onthe network 110. The client ORB 124 includes code to performmarshalling, meaning it encodes the operation and its parameters intoflattened GIOP message format that is can send through the network 110to the server computer 130.

At the server computer 130, the IDL skeletons 134 provide the staticinterfaces to each service exported by the server. These skeletons, likethe stubs on the client computer 120, are created using an IDL compiler.Using these skeletons, the server ORB 134 transforms the flattened GIOPmessages into operations and parameters understood by the object X inthe sever computer 130. Thereafter, the object X executes the desiredoperation and, if necessary, returns the requested data back to theclient computer 120 through the ORB.

Conventional ORB models have been in use in distributed software systemsfor years. In recent years, ORB software has been developed that can runon a microcontroller or a digital signal processor (DSP). An applicationmay, however, be developed directly as a hardware component such anApplication-Specific Integrated Circuit (ASIC)—an integrated circuitcustomized for the particular purposes of the application.Alternatively, an application may be implemented in a programmable logicdevice that does not implement a fixed function, but instead consists ofa sea of logic gates and connection resources that can be configured toperform a desired function.

A popular programmable semiconductor device used today is a FieldProgrammable Gate Array (FPGA), which is a device containingprogrammable logic components and programmable interconnects. The logicand interconnect components of the FPGA can be programmed by a logicdesigner to perform a desired functionality. An FPGA is slower than itsASIC counterpart, consumes more power, and may be unfit for very complexapplications. However, an FPGA provides certain advantages over an ASIC,which include the ability to reprogram at will, a shorter time tomarket, the ability to fix bugs, and lower Non-Recurring Engineering(NRE) costs.

In order for hardware components such as ASICs, PLDs, and FPGAs to beeffectively incorporated into a distributed system, they need to beequipped with an ORB interface capable of transforming software requestsinto signals understood by the hardware components. Likewise, thehardware must be capable of generating requests understood by thesoftware components. A conventional method of connecting hardware deviceto distributed system is through a custom proxy operating on a GeneralPurpose Processor (GPP) or a Digital Signal Processor (DSP) thatprovides an interface between the hardware device and asoftware-implemented ORB. This approach has the significant disadvantageof creating a performance bottleneck in the GPP proxy.

Alternatively, the hardware designers may implement a customapplication-specific ORB module within the hardware device. However,this method requires hardware designers to understand CORBA as well asObject Oriented Programming—areas that many hardware designers are notfamiliar with. Also, an ORB module custom-designed for a particularapplication block may not be readily reusable, since code mapping wouldhave to be embedded within the module for the particular application.

U.S. Patent Application No. 2005/0108382 to Murotake et al. discussesimplementing an ORB on an FPGA within a Reconfigurable CommunicationsArchitecture (RCA) radio system. This publication, however, does notdisclose how an ORB is to be implemented.

An Integrated Circuit ORB (ICO), developed by PrismTech Ltd., offers anembedded ORB written in portable VHDL that can be mapped onto on anFPGA. The ICO consist of an ICO engine, an IDL to VHDL code generator,the Spectra Modeling Tool, and the SCA (Software CommunicationArchitecture) component. The SCA is an architecture framework thatdefines how hardware and software elements communicate within a softwaredefined radio. An ICO engine is responsible for implementing thetransfer syntax used by CORBA. The engine demarshals the incoming GIOPmessages and extracts header and data fields from the messages. For theincoming messages, the engine performs operation name demultiplexing todetermine which object the data in the GIOP message is being transferredto. Message data is then extracted by the engine to transfer to theappropriate FPGA logic block. If a reply is requested, the engine willperform a read operation to an object to obtain the necessary data forthe reply. It also populates the header field and builds a reply messageto in compliance with the GIOP standard.

Although the ICO allows for FPGA applications to communicate through anORB, there exists a need to provide a better mechanism for allowinghardware implemented applications to communicate with each other in amore robust fashion.

Moreover, the ICO presents a disadvantage for FPGA developers. In theICO, the ICO engine must know of the location and functions of eachapplication module in order to extract the appropriate header from themessages and perform operation name demultiplexing and data routing tothe appropriate objects. The ICO IDL-to-VHDL code generator generatesconfiguration parameters needed by the ICO engine. This code generatoralso adds these parameters to VHDL package files that configure thephysical aspects of the ICO interface and internal storage elements.Therefore, parts of the VHDL code for the ICO's ORB core are generatedat compile time by the code generator. As a result, if the FPGA designerwishes to reconfigure the functionality of an application block withinthe FPGA, the entire ORB module must be also be reconfigured andregenerated. This may be problematic to many FPGA designers in that itprecludes the ability to partially reconfigure the FPGA withoutaffecting the operation of the ORB and other FPGA modules.

SUMMARY OF THE INVENTION

Briefly, a communication system according to one aspect of the presentinvention, comprises one or more integrated circuits. The one or moreintegrated circuits comprise at least one of a local integrated circuitand a remote integrated circuit. At least one sending applicationhardware module located on the local integrated circuit has a sendinglogic that controls the sending of messages from the sending applicationhardware module. At least one receiving application hardware module islocated on at least one of the local integrated circuit or remoteintegrated circuit. A sending application hardware module sends messagesto a receiving application hardware module without its sending logichaving been constructed with a priori knowledge of the address of or thepath to said receiving application hardware module. A dispatch logiclocated on the local integrated circuit that routes at least one or moreof:

A) messages transmitted from the sending application hardware module onto one or more receiving application hardware modules on the localintegrated circuit, or

B) messages transmitted from the sending application hardware module fortransport to one or more receiving application hardware modules locatedon a remote integrated circuit.

According to some of the more detailed features of this aspect of theinvention, the communication system of further included one or moreprocessors remote to the local integrated circuit running one or morereceiving application software programs. A sending application hardwaremodule in the local integrated circuit sends messages to a receivingapplication software program executed on a remote processor without itssending logic having been constructed with a priori knowledge of theaddress of or the path to said receiving application software program,and wherein the dispatch logic routes at least one or more of themessages transmitted from the sending application hardware module fortransport to the receiving application software program.

According to another aspect of the invention, an integrated circuitcomprises a plurality of middleware-enabled application blocks. Eachmiddleware-enabled application block comprise one or more applicationmodules that contain one or more application objects and use one or moreapplication-specific interface indicators for processing messages. Atransmit operation adapter associated with each middleware applicationblock transmits one or more outbound operation names and objectindicators, and a receive operation adapter associated with eachmiddleware application block receives inbound operation names and objectindicators. Each receive operation adapter of a middleware-enabledapplication block converts at least one inbound operation name based onthe inbound object indicator to a corresponding application-specificoperation indicator for use by an application object of a correspondingapplication module specified by the object indicator. Each transmitoperation adapter of a middleware-enabled application block converts atleast one application-specific operation indicator specified by anapplication object of a corresponding application module to acorresponding outbound operation name. An operation name from a transmitoperation adapter in one application block is conveyed to a receiveoperation adapter of another application block based on an objectindicator from said transmit operation adapter. This aspect of thepresent invention allows for partial reconfigurability of an FPGA thatimplements the application blocks such that each application block canbe reconfigured without impaction any other application block.

According to some of the more detailed features of this aspect of theinvention, a message router conveys one or more messages each containingan optional operation name, an optional object indicator, and other datafrom the plurality of middleware-enabled application blocks and directsone or more outbound operation names and object indicators to theplurality of the middleware-enabled application blocks. A dispatchmodule coupled to the message router that brokers object service requestand reply messages over a communication transport external to theintegrated circuit according to a defined protocol. The object servicerequest messages comprise inbound data messages including one or moreinbound operation names and object indicators and outbound data messagesincluding one or more outbound operation names and object indicators.The object service reply messages comprising inbound data messagesincluding object service request context information and outbound datamessages including object service request context information. Therouter applies an outbound operation name directed from an applicationmodule for communication over the transport to the dispatch module to betransported in accordance with the protocol.

According to still another aspect of the preset invention, areconfigurable filed programmable gate array comprises a plurality ofmiddleware-enabled application blocks. Each middleware-enabledapplication block comprises one or more application modules that containone or more application objects that use one or moreapplication-specific interface indicators for processing messages. Theone or more application-specific interface indicators associated with anapplication module of one application block are reconfigured whilemaintaining the one or more application-specific interface indicatorsassociated with another application module of another application block.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a conventional ORB model connecting a client computer toa server computer within a network.

FIG. 2( a) is a block diagram for transparent communication of messagessent from a hardware implemented application module.

FIG. 2( b) depicts an embodiment of the present invention employing acrossbar switch

FIG. 3 depicts an embodiment of the present invention employing aninternal BUS.

FIG. 4 depicts an embodiment of the present invention employing directrouting.

FIG. 5 depicts an exemplary format an inbound request message processedthrough the ORB and the Receive Operation Adapter.

FIG. 6 depicts an exemplary format of an outbound request messageprocessed through the Transmit Operation Adapter and the ORB.

FIG. 7 depicts an exemplary format of a reply message processed throughthe Transmit Operation Adapter and the ORB.

FIGS. 8( a) and 8(b) depict exemplary formats of the REQUEST_CONTROL andREPLY_CONTROL shown in FIGS. 6-7.

FIG. 9 depicts a flow chart of the method of implementing an FPGA havingan ORB according to embodiments of the present application.

FIG. 10 depicts an example an FPGA having an ORB according toembodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the present invention are now disclosed with reference tothe drawings. Although embodiments of this invention are depicted anddescribed with reference to an FPGA, it must be understood that thepresent invention may be utilized in any integrated circuit such asProgrammable Logic Devices (PLDs), Application Specific IntegratedCircuits (ASICs), or in computing platforms based on technology otherthan semiconductor (e.g. optical computing). It must also be understoodthat although embodiments of the present invention describe a dispatcheras an ORB system implementing the CORBA standards, communicationsmiddleware systems and dispatchers implementing other standards may alsobe used with the method and system of the present invention.

One aspect of the invention relates to a communication system thattransparently communicates messages between one or more hardwareimplemented application modules that send or otherwise transmit messagesand one or more of hardware implemented hardware modules or softwareimplemented application programs that receive the sent or otherwisetransmitted messages.

FIG. 2 (a) shows a system that provides messaging between a sendingapplication hardware module on a local integrated circuit and areceiving application hardware modules or a receiving applicationsoftware program according to this aspect of the present invention. Themessaging transparency is provided by the sending application hardwaremodule sending messages to a receiving application hardware module or areceiving application software program without the sending logic of suchapplication hardware module having been constructed with a prioriknowledge of the address of or the path to the receiving applicationhardware module or the application software program. In other words, thesending logic is constructed without any knowledge of the address of orthe path to the receiving application hardware module or the applicationsoftware program. So, when constructed initially no address of or thepath to the receiving application hardware module or the applicationsoftware program is embedded in the sending logic.

In one embodiment, the communication system provide inter-chip, namelycommunication transparency between one application hardware module andanother application hardware module within an integrated circuit. Underthis embodiment, the communication transparency is between a sendingapplication hardware module and a receiving application hardware moduleboth of which are located one the same local integrated circuit. Thesystem of the present invention can also provide intra-chipcommunication transparency between the sending application hardwaremodule in the local integrated circuit and a receiving applicationhardware module in a remote integrated circuit. In still anotherembodiment, the system of the present invention provides messagingtransparency between the sending application hardware module on thelocal integrated circuit and the receiving application software programsthat is executed on one or more remote processors, for example, on aclient station or a communication node. Regardless, the sending logic ofthe sending application hardware modules on the local integrated circuithas no a priori knowledge of the address of or the path to the receivingapplication hardware module or the receiving application softwareprogram and communicates messages transparently.

In the communication system of the present invention, a hardwareimplemented dispatch module, such as a hardware implemented middlewarecompliant with an ORB protocol, brokers communication of messages. Thedispatch logic is located on the integrated circuit that routes at leastone or more of the messages sent or transmitted from the sendingapplication hardware module on the local integrated circuit to one ormore receiving application hardware modules on the same local integratedcircuit. Alternatively, the dispatch logic routes messages transmittedfrom the sending application hardware module on the local integratedcircuit for transport to either the receiving application hardwaremodule located on the remote integrated circuit or the applicationsoftware program run by the remote processor.

Referring now to FIG. 2 (b), there is depicted an embodiment of an FPGAsystem 200 according to the present invention. The FPGA comprises aplurality of application blocks 240 a, 240 b, etc., each having acorresponding application modules. Each application module comprises oneor more application objects that perform a specified function using acorresponding interface and operation indicators, that can be numericvalues or strings contained in messages. As shown, the application block240 a, for example, includes the application module 242, the ReceiveOperation Adapter (ROA) 250, and the Transmit Operation Adapter (TOA)252. The ROA 250 and the TOA 252 interface with the application module242 and act as a bridge between the application module 242 and a messagerouter that routed inbound and outbound messages. In the exemplary FPGAof FIG. 2( b), the message router comprises a crossbar switch 230, whichconveys messages within the FPGA locally, amongst the application blocks240 a, 240 b, etc.. The FPGA also conveys messages to remotedestinations outside the FPGA over a transport through an ORB thatcomprises ORB Receive 220 and ORB Transmit 222. The ORB Receive 220 andORB Transmit 222 are connected to an outside network through the ReceiveTransport Adapter (RTA) 210 and the Transmit Transport Adapter (TTA)212, respectively. The Receive Transport Adapter (RTA) 210 and theTransmit Transport Adapter (TTA) 212 may encompass any type ofcommunication port capable of transferring data in and out of the ORB,such as a PCI port, a USB port, an Ethernet port, a serial port, etc.Incoming messages are received by the RTA 210 and passed on to the ORBReceive 220. Outgoing messages are sent from the ORB Transmit 222through the TTA 212 to the outside world. If multiple externalcommunication ports are available to the FPGA, multiple interoperableORBs, along with their associated RTA and TTA modules, can beinstantiated.

The implementations of the ORB Receive 220 and the ORB Transmit 222 inthe FPGA 200 are well known and can be placed anywhere in the FPGA 200that the designer desires. The RTA 210 and the TTA 212, are typicallycustom-designed by the FPGA designer in accordance with the requirementsof the application blocks 240 a, 240 b, etc.. However, the type of portdesign used for the RTA 210 and the TTA 212 does not affect the ORBReceive 200 and ORB Transmit 222 modules, since the ORB Receive 200 andORB Transmit 222 are independent and separate from the RTA 210 and theTTA 212.

The ORB Transmit 222 performs a similar function as the client ORB 124and IDL Stubs 126 previously described with reference to FIG. 1.Similarly, the ORB Receive 220 performs a similar function to server ORB134 and IDL Skeletons 136. When a request or reply is generated by anapplication module within the FPGA 200, the ORB Transmit 222 createsGIOP messages, which are then sent out, through the TTA 212, to a remotedestination ORB, for example to the dispatcher in the remote integratedcircuit of FIG. 1.

When a request is sent from an external or otherwise remote ORB to theFPGA 200, e.g., a request from the dispatcher in the remote integratedcircuit of FIG. 1, the ORB Receive 220 transforms the GIOP packets intoa compact internal representation that can then be readily processedwithin the FPGA. As further described below, all application blocks 240a, 240 b, etc., within the FPGA process messages in the same mannerregardless f whether a message is originated locally from anotherapplication block within the FPGA or originated remotely from outside ofthe FPGA. The compact internal representation includes a string-based‘operation name’, which is operation that an application module 242 onthe FPGA 200 has been requested to perform, along with the necessaryparameters.

In addition to the ORB Receive 220 and the ORB Transmit 222, the ORBfunctionality may also include the cross bar switch 230. Alternatively,the designer may choose to implement their own cross bar switch 230. Thecrossbar switch 230 can be placed in any part of the FPGA 200 as long asit can connect the ORB Receive 220 and the ORB Transmit 222 to allapplication blocks 240 a, 240 b, etc. that the ORB needs to communicatewith. The exemplary embodiment in FIG. 2 depicts a 4-port crossbarswitch 230 connected the ORB Receive 220 and the ORB Transmit 222 to aplurality of application blocks 240 a, 240 b, and 240 c. However, it ispossible to use a variety of other switches such as partially-connectedcrossbars, fully-connected crossbars, banyan switches, memory switches,etc. It is also possible to include any number of ports on the switch230 depending on the number of application blocks on the FPGA. Further,more than one ORB may be included in the FPGA, in which case each ORBwould be designated a port on the switch 230. In FIG. 2, the ORB Receive220 and ORB Transmit 222 may be connected to port ‘00’, the applicationblock 240 a may be connected to port ‘01’, the application block 240 bmay be connected to port ‘10’, and the application block 240 c may beconnected to port ‘11’ and so on.

As stated above, each middleware-enabled application block, such asapplication block 240 a, a Receive Operation Adapter (ROA) 250, aTransmit Operation Adapter (TOA) 252, which act as a bridge between theapplication module 242 and the crossbar switch 230. A transmit operationadapter associated with each middleware application block transmits oneor more outbound operation names and object indicators. A receiveoperation adapter associated with each middleware application blockreceives inbound operation names and object indicators. Each receiveoperation adapter of a middleware-enabled application block converts atleast one inbound operation name based on the inbound object indicatorto a corresponding application-specific operation indicator for use byan application object of a corresponding application module specified bythe object indicator. Each transmit operation adapter of amiddleware-enabled application block converts at least oneapplication-specific operation indicator specified by an applicationobject of a corresponding application module to a corresponding outboundoperation name. An operation name from a transmit operation adapter inone application block is conveyed to a receive operation adapter ofanother application block based on an object indicator from saidtransmit operation adapter.

In the exemplary embodiment of FIG. 2 (b), the ROA 250 includes a lookup table containing operation names and corresponding enumeratedoperation indicator values. An operation name is a string of charactersand constitutes what is known to the outside world as a command that anapplication module such as application module 242, is able to execute.For example, an operation name can be “fire”, “reload”, or “shut down”.The application module 242 is configured to recognize enumeratedoperation indicator values associated with that operation names as afunction. For example, the enumerated operation indicator value for“fire” may be 0, the enumerated operation indicator value for “reload”may be 1, and the enumerated operation indicator value for “shut down”may be 2. The enumerated operation indicator values are unique to aparticular application module and application objects contained therein.Therefore, while the 0 may be associated with “fire” within theapplication block 240 a, it may be associated with another operationsuch as “measure temperature” in application block 240 b. Because thelook up table is contained in the ROA 250, and is therefore directlyassociated with the application module 242, the application can bedynamically reconfigured without impacting the rest of the system andwithout requiring additional external configuration effort.

The TOA 252 includes a set of tables used to convert enumeratedoperation indicator values for operation names and enumerated objectindicator values for object keys into, respectively, fully expandedstrings and octet sequences. Once again, because this data is containedin the TOA 252, and is therefore directly associated with theapplication module 242, the application can be dynamically reconfiguredwithout impacting the rest of the system.

During the implementation of the FPGA 200, the ROA 250 and the TOA 252are generated from an IDL model using an IDL-to-VHDL compiler. The IDLmodel describes the content of the ROA 250 and the TOA 252. Within theIDL model, there are entries for each every operation supported byapplication objects of the application module 242, which include theenumerated operation indicator value, the operation name, and a list ofparameters for each operation. To configure and create an IDL model foran application block 240, a systems architect needs only to modify theoperation names and parameters for each operation. Therefore, creatingthe IDL model does not require a designer to have a thoroughunderstanding of IDL programming Thus, a reconfigurable FPGA accordingto the present invention has a plurality of middleware-enabledapplication blocks having one or more application objects that use oneor more application-specific interface indicators, such as values orstrings. The application-specific interface indicators are describe by ahardware defined language, e.g., VHDL, that implements each applicationblock on the FPGA. According to this aspect of the invention, anapplication-specific indicator associated with one application block canbe modified, updated or reconfigured dynamically without having tomodify any other description of the hardware defined language thatimplements any other application block.

In additional to generating VHDL code for the ROA 250 and TOA 252, theIDL compiler generates documentation describing, in detail, the formatand location of all Operation data elements within the GIOP messagepayload. This reduces or eliminates the need for the FPGA designer tobecome familiar with GIOP message formats and Common Data Representation(CDR) marshalling/demarshalling rules.

The IDL-to-VHDL compiler compiles the IDL model into VHDL code that willbe used to synthesize the ROA 250 and the TOA 252 for each applicationblock 240 a, 240 b and 240 c. Since the ROA 250 and TOA 252 aregenerated independently from all the other ORB modules previouslydescribed, an FPGA designer may reconfigure any application block 240 a,240 b or 240 c of the FPGA 200 without having to reprogram andreconfigure the other ORB modules. Therefore, for example, ifapplication module 242 within the application block 240 a needs to beupdated or modified, the systems architect needs only to create a newIDL model for the new application module 242 and run the IDL-to-VHDLcompiler to create new ROA 250 and TOA 252 for the application block240. However, the ORB Receive 220, the ORB Transmit 222, the RTA 210,the TTA 212, and the crossbar switch 230 need not be modified.

During the operation of the FPGA, when a GIOP request packet is receivedby the RTA 210, the packet is passed on to the ORB Receive 220. The ORBReceive 220 process and reformats the message header to create a compactinternal representation that is optimized for stream processing. Theoptimized header will include, among other information, an operationname in the form of a string, the message data which includes theparameters for the desired operation, and an object key, which includesdesignates the destination address of the packet. The destinationaddress corresponds to the application block where the packet is to besent. The data packet is then sent the crossbar switch 230.

The switch 230 routes the packet that it receives from the ORB Receive220 to the destined application block 240 a. The incoming packets areprocessed by the ROA 250 before being sent to the application module242. The object indicator bits [5:0] of the object key indicates theappropriate interface for each application object in the applicationmodule. As previously described, the ROA 250 contains a look up tablefor converting the string operation names appropriate for the targetobject's interface to enumerated operation indicator values. If themessage received at the ROA 250 originated from the ORB Receive 250, themessage will include an operation name in the form of a string. In thatcase, the ROA 250 looks up the operation name and coverts it into acorresponding enumerated value. The ROA 250 then passes the packet on tothe application block 240. If, however, the packet is routed fromanother application block 240 b to the application block 240 a, thepacket would already include the enumerated value. In that case, the ROA250 passes on the packet to the application module 242 withoutmodification. This behavior isolates the FPGA application from knowledgeregarding the internal or external origin of a message, providinglocation transparency.

If the operation requires a reply, the application module 242 willgenerate a reply message and send it to the crossbar switch 230 throughthe TOA 252. The message is then sent from the crossbar switch 230 tothe ORB transmit module 222, which generates a complete GIOP message.The GIOP message is then sent out through the TTA 212. Requestsinitiated by the application blocks 240 are similarly transferred.

In another embodiment of the present invention, the task of the TOA 252is limited to sending information to the ORB Receive 220 and ORBTransmit 222 at boot time. In this embodiment, the data sent by the TOA252 to the ORB Transmit 222 at boot time includes information about howto convert the enumerated operation indicator values back into stringoperation names. Therefore, in this embodiment, the ORB Transmit willhave to include a storage means for storing the enumerated operationindicator values associates with each operation that will be invoked byeach application block 240 a. At operation time, every time theapplication module 242 initiates a request message or sends a replymessage to the ORB Transmit 222, the TOA 222 transmits the messagethrough without any modification. Therefore, the message received by theORB Transmit 222 will include the enumerated operation indicator valuesinstead of the operation names. The ORB transmit 222 then translates theenumerated types to operation names before creating the GIOP message.

FIG. 3 depicts an alternative embodiment of the present inventionemploying a router in the form of a bus 330 instead of a switch. In thisembodiment, the ORB Receive 220 sends messages to the BUS 330, whichwill deliver messages to the destination application block 240 a usingthe address information in the message header.

FIG. 4 depicts yet another embodiment of the present invention whereinmessages between all application blocks 440 are routed serially. In thisembodiment, the ORB Receive 210 sends a message through a series ofapplication blocks until the desired application block to which themessage has been addressed receives and processes the message.Thereafter, the application block may issue a reply, which may again gothrough a series of other applications before being received by the ORBtransmit 222. In order to increase throughput, all connections may bepipelined using pipes 430. Accordingly, the ORB Receive 210 may issuedifferent requests to the initial application block at each clock cycle,instead of having to wait for a reply to come back before issuing a newrequest. Alternatively, the series of application blocks 440 may beconnected without pipelining.

FIG. 5 depicts an exemplary format an inbound request message processedthrough the ORB and the ROA. The Transport Request Message 520 is a GIOPmessage having fields required by the GIOP standard. Since most thesefields are not necessary for the operation of an internal FPGAapplication, the ORB reduces the message 520 to a Post-ORB RequestMessage 530. The message 530 includes the operation name as a string,which, in the example previously provided, may be “fire”, “reload”,“shut down” or “measure_temperature”. The message 530 also includes aREQUEST_CONTROL, which will be described later with reference to FIG. 8a, as well as a request_id, a data_payload_size, and message data. Themessage data includes the parameters that are sent to the application toexecute the specific operation.

FIG. 6 depicts an exemplary format of an outbound request messageprocessed through the Operational Transmit Adapter and the ORB. AnApplication Request Message 610 is received by the Operation TransmitAdapter, which looks up the operation name (string) for the desiredoperation enumerated value and adds the operation name to the message620. The message 620 is then converted by the ORB to Port ORB (ToTransport) Request Message 630, which conforms to the GIOP standards.

FIG. 7 depicts an exemplary format of a reply message processed throughthe Operational Transmit Adapter and the ORB. The Application ReplyMessage 710 is similar to the Application Request Message 610 shown inFIG. 6, except that it includes a REPLY_CONTROL instead of aREQUEST_CONTROL. Similarly, the Post-Op Adapter Reply Message 720 issimilar to the Post-Op Adapter Request Message 620, except that itincludes a REPLY_CONTROL.

FIGS. 8 (a) and 8 (b) depict exemplary formats of the REQUEST_CONTROLand REPLY_CONTROL shown in FIGS. 6-7, which are both 32-bit fields. Thefield description of REQUEST_CONTROL and REPLY_CONTROL are provided asfollows.

REQUEST CONTROL Field Description Destination Object Address

Bits [10:6] indicate the internal physical destination for the message.For outgoing Request messages these bits are set to the transmit ORBadapter (all zeros). For incoming and local Request messages these bitsare set to the target Operation adapter.

Bits [5:0] indicate the internal logical destination within the physicaldestination for the message. For incoming, local, or outgoing Requestmessages these bits are set to the a value appropriate to indicate theObject Id for the servant invoked upon.

Source Object Address

Bits [10:6] indicate the internal physical source of the message. Forincoming Request messages these bits are set to the receive ORB adapter(all zeros). For outgoing and local Request messages these bits are setto the source Operation adapter.

Bits [5:0] indicate the internal logical source within the physicalsource of the message. For incoming, local, or outgoing Request messagesthese bits are set to the a value appropriate to indicate the Object Idfor the invoking servant.

Byte Order—CORBA-defined Boolean value indicating byte ordering forincoming message.

-   -   1=Little Endian, 0=Big Endian

Message Type (MT)—Message Type field indicator Boolean value.

-   -   0=Request, 1=Reply

Response Expected (RE)—CORBA-defined Boolean value indicating if aresponse is

-   -   expected to this request. 0=No Response Expected, 1=Response        Expected

Enumerated Operation

Operation adapters interpret this as an enumerated operation indicator.

REPLY CONTROL Field Description Destination Object Address

Bits [10:6] indicate the internal physical destination for the message.For outgoing Reply messages these bits are set to the transmit ORBadapter (all zeros). For incoming and local Reply messages these bitsare set to the target Operation adapter.

Bits [5:0] indicate the internal logical destination within the physicaldestination for the message. For incoming, local, or outgoing Replymessages these bits are set to the a value appropriate to indicate theObject Id for the invoking client servant.

Source Object Address

Bits [10:6] indicate the internal physical source of the message. Forincoming Reply messages these bits are set to the receive ORB adapter(all zeros). For outgoing and local Reply messages these bits are set tothe source Operation adapter.

Bits [5:0] indicate the internal logical source within the physicalsource of the message. For incoming, local, or outgoing Reply messagesthese bits are set to the a value appropriate to indicate the Object Idfor the servant invoked upon.

Byte Order—CORBA-defined byte ordering for incoming message.

-   -   1=Little Endian, 0=Big Endian

Message Type (MT)—Message Type field indicator Boolean value.

-   -   0=Request, 1=Reply. Must be Reply (b″1″).

Reply Status (RS)—CORBA-defined. Should typically be NO_EXCEPTION

-   -   (b″000″)

FIG. 9 depicts a flow chart of the method of implementing an FPGA havingan ORB or ORBs according to embodiments of the present application. TheIDL Interface 910 and IDL Metadata 912 are provided to the IDL to VHDLcompiler, block 914. The IDL to VHDL compiler uses the data to generatethe necessary operation interfaces for each application in VHDL, block920. Thereafter, the operation interfaces merge with the userapplications to create the application blocks in VHDL or Verilog, block922. The application blocks then combine with the FPGA ORB 932, which isin an EDIF Netlist format, and the Transport Adapters models 934, whichare in VHDL, EDIF, or software format, to complete the VHDL model of theFPGA, block 930. The VHDL model is then simulated using the simulationenvironment 942 provided in VHDL, block 940. After successfulsimulation, the VHDL model of the FPGA is synthesized, block 950, tocreate en EDIF Netlist, block 952. The EDIF Netlist can then be placedon and routed through the FPGA, block 954. Finally, a bit file iscreated, block 956, which is used to program the FPGA, block 960.

FIG. 10 depicts an exemplary block diagram of a software defiled radio(SDR) implemented according to the embodiments of the present invention.The SDR is implemented on an integrated circuit, such as an FPGA, with aplurality of middleware-enabled application blocks, such as a spreaderblock, a despreader block, an encoder block and DAC/ADC blocks etc. Eachmiddleware-enabled application block comprise one or more applicationmodules, that contain one or more application objects that perform thenecessary SDR functions, including signal spreading, dispreading,encoding and A/D and D/A conversion functions, etc.. These applicationobjects use corresponding application-specific interface indicators forprocessing messages transparently, as described above, within theintegrated circuit locally and without the integrated circuit remotelyover a transport.

As shown, a transmit operation adapter and a receive operation adapteris associated with each middleware application block for communicatinginbound and outbound messages and processing/converting operation namesand object indicators as described above. Each receive operation adapterof a middleware-enabled application block converts at least one inboundoperation name based on the inbound object indicator to a correspondingapplication-specific operation indicator for use by an applicationobject of a corresponding application module specified by the objectindicator. Each transmit operation adapter of a middleware-enabledapplication block converts at least one application-specific operationindicator specified by an application object of a correspondingapplication module to a corresponding outbound operation name. A messagerouter in the form of a cross bar switch conveys the messages within theintegrated circuit between the application blocks locally. A dispatchmodule, comprising ORB receive and ORB transmit blocks, is coupled tothe message router that brokers object service request and replymessages over a communication transport external to the integratedcircuit according to a defined protocol, such as CORBA. The objectservice request messages comprise inbound data messages including one ormore inbound operation names and object indicators and outbound datamessages including one or more outbound operation names and objectindicators. The object service reply messages comprise inbound datamessages including object service request context information andoutbound data messages including object service request contextinformation. The message router applies an outbound operation namedirected from an application module for communication over the transportto the dispatch module to be transported in accordance with theprotocol.

As stated above, the present invention allows for partial and dynamicreconfigurability of the FPGA that implements the SDR application blockssuch that each application block can be reconfigured without impactingany other application block. For example, the spreader block interfacescan be updated or modified without having to reconfigure any other SDRfunctional block. Thus, the FPGA that implements the SDR is areconfigurable filed programmable gate array that comprises a pluralityof middleware-enabled application blocks, namely, the spreader,despreader, encoder, DAC/ADC blocks etc. Each middleware-enabledapplication block has one or more application objects that performSDR-related functions. They use one or more application-specificinterface indicators for processing messages. The one or moreapplication-specific interface indicators associated with oneapplication block can be dynamically reconfigured or modified withoutmodifying the one or more application-specific interface indicatorsassociated with another application block.

1. A communication system, comprising: one or more integrated circuitscomprising at least one of a local integrated circuit or a remoteintegrated circuit to the local integrated circuit; at least one sendingapplication hardware module located on the local integrated circuit,each sending application hardware module having a sending logic thatcontrols the sending of messages from the sending application hardwaremodule; at least one receiving application hardware module located on atleast one of the local integrated circuit or the remote integratedcircuit; wherein a sending application hardware module sends messages toa receiving application hardware module without its sending logic havingbeen constructed with a priori knowledge of the address of or the pathto said receiving application hardware module, and a dispatch logiclocated on the local integrated circuit that routes at least one or moreof: A) messages transmitted from the sending application hardware moduleon to one or more receiving application hardware modules on the localintegrated circuit, or B) messages transmitted from the sendingapplication hardware module for transport to one or more receivingapplication hardware modules located on a remote integrated circuit. 2.The communication system of claim 1, further including one or moreprocessors remote to the local integrated circuit running one or morereceiving application software programs, wherein a sending applicationhardware module in the local integrated circuit sends messages to areceiving application software program executed on a remote processorwithout its sending logic having been constructed with a prioriknowledge of the address of or the path to said receiving applicationsoftware program, and wherein the dispatch logic routes at least one ormore of the messages transmitted from the sending application hardwaremodule for transport to the receiving application software program.
 3. Acommunication system, comprising: one or more integrated circuits; oneor more processors remote to the one or more integrated circuits runningone or more application software programs; at least one sendingapplication hardware module in an integrated circuit having a sendinglogic that controls the sending of messages from the sending applicationhardware module, wherein the sending application hardware module sendsmessages to a receiving application software executed on a remoteprocessor without its sending logic having been constructed with apriori knowledge of the address of or the path to said receivingapplication software program, and a dispatch logic located on theintegrated circuit that routes at least one or more of the messagestransmitted from the sending application hardware module for transportto the receiving application software programs.
 4. The communicationsystem of claim 3, wherein the dispatch logic routes at least one ormore of: A) messages transmitted from the sending application hardwaremodule on to one or more receiving application hardware modules on thesame integrated circuit, or B) messages transmitted from the sendingapplication hardware module for transport to one or more receivingapplication hardware modules located on a remote integrated circuit. 5.A reconfigurable filed programmable gate array (FPGA), comprising: aplurality of middleware-enabled application blocks; eachmiddleware-enabled application block comprising one or more applicationobjects that use one or more application-specific interface indicators,said one or more application-specific interface indicators beingdescribe by a hardware defined language that implements each applicationblock on the FPGA, wherein an application-specific indicator associatedwith one application block is modified dynamically without modifying anydescription of the hardware defined language that implements any otherapplication block.